Public key cryptography is an approach to enabling secure communications using key pairs. Each key pair includes a public key and a private key. The public key and private key are related so that, for example, a message encrypted by one key may be decrypted only by the other, but it is computationally infeasible to deduce the private key given the public key. In addition to message encryption, the key pair may be used to perform other functions as well. The private key is typically created and securely held by an entity; while the corresponding public key is typically made widely available. Secure communications between parties may then be enabled by using the parties' public and private keys.
The use of public key cryptography addresses many of the inherent security problems in an open network such as the Internet. However, two significant problems remain. First, parties must be able to access the public keys of other entities in an efficient manner. Second, since in many protocols entities are associated with and in some sense identified by their public keys, there must be a secure method for parties to verify that a certain public key is bound to a certain entity.
A public key infrastructure (PKI) system addresses these two problems. In one common approach, the public key infrastructure is based on digital certificates, which are used to associate a certain public key pair to a certain entity with some degree of integrity. The public key management infrastructure typically would include a database of digital certificates, certification authorities who issue the certificates, and other infrastructure for authenticating parties. A number of digital certificate services are typically provided in order to establish, disseminate, maintain, and service the public keys and associated digital certificates used in a PKI. These services are typically provided to end users by CAs or third party operators. The digital certificate services provided typically include the following: enrollment, status report, retrieval and search services as well as validation, revocation, renewal and replacement services.
FIG. 1 shows one example of a format for identity data such as a digital certificate 100. In some implementations, the digital certificate 100 may comply with the ITU-T Recommendation X.509 (1997 E), as developed by the ISO/IEC/ITU groups. Of course, other certificate formats and other types of identity data may be employed as well. The digital certificate 100 includes attributes providing technical information such as a certificate serial number 101. Another attribute, attribute 102 specifies the digest algorithm used in generating the certificate signature. The attribute 103 specifies the signing algorithm (such as RSA or ECC) used in conjunction with the digest algorithm 102 when generating the certificate.
The digital certificate 100 also includes the Subject Name attribute 104, which describes the entity whose public key is being certified, who is sometimes referred to as the Subject. X.509 certificates use distinguished names (DNs) as the standard form of naming. A DN is typically made up of the following components: CN=common name, OU=organizational unit, O=organization, L=locality, ST=state or province, C=country name. The Common Name (CN) of the Subject attribute is normally a required data field. Some possible values for the CN are a hardware-based identifier such as a MAC Address or IMEI, a DNS hostname, or a person's name.
The digital certificate 100 also includes attribute 105, sometimes referred to as the certificate issuer name, which refers to the Certificate Authority (CA) issuing the digital certificate 100 to a Subject. A CA is an entity who issues other digital certificates. The CA has its own digital certificate associated with the key used for signing other entity's certificates. A copy of a CA's digital certificate would be necessary to validate the digital certificate 100 issued by the CA.
The digital certificate 100 also includes the entity's Subject Public Key 106 which is a value generated using an asymmetric cryptographic algorithm (such as RSA or ECC). Included as well is the validity period attribute 107 which is the start and end date during which the certificate is considered valid. The start date in the validity period 107 is generally the date and time that the issuing CA signed the certificate.
Each of the attributes described above, except for the Issuer Name, are to be populated with entity-specific data. The Issuer Name information 105 would be common to all certificates issued by the same Issuer 105.
After a digital certificate 100 is confirmed to be issued by the Issuer 105, a chain of trust must be validated as shown in FIG. 1. This is performed by verifying that the certificate associated with the Issuer 105 is valid as well. Performing this verification step requires a copy of the digital certificate 100 associated with Issuer 105 for every certificate being validated. The cryptographic signature verification is performed on every digital certificate using the Issuer's certificate. This step is repeated until the Issuer Name 105 in the digital certificate 100 is the same as the Subject Name 104 in the same certificate. A certificate with an Issuer Name attribute equal to the Subject Name attribute is called a Root Certificate and must be trusted. A Root Certificate is associated with a specially trusted entity and is an integral part of every PKI.
In the era of information technology, PKI technology is being widely adopted by organizations to implement security features in the products and services they provide. A well implemented PKI system and its associated practices and procedures are often deeply involved in the organization's product development process, from the design phase all the way to the manufacturing phase. However, each organization typically has its own security policy, different manufacturing processes, and a unique style of engineering collaboration. All these differences have led to the development of complex and customized PKI systems that need to be maintained by each organization.
The scenario becomes even more complex when the security policy is defined and enforced by an external party, such as a consortium. As more and more standards or technologies are developed by multiple companies in collaboration with one another, consortiums are becoming a popular entity used to protect the best interests of all parties involved. Consequently, the integration between the consortium's PKI system and a participant organization's home-grown PKI system becomes an important but challenging task that every participant organization has to deal with. In some cases an organization is involved in multiple consortiums due to the diversified nature of many product development projects. For the consortiums, maintaining a sophisticated PKI system that supports the various security requirements imposed by the participating companies can be overwhelmingly difficult.